Those who use communication services may employ a wide variety of cryptographic techniques and corresponding devices to engage in secure communication sessions. In a typical scenario, two parties first establish a "plain-text" or "clear" call through a telecommunications or other communication network. At this point, no significant encryption is being employed and clear, rather than secure, communications are taking place. One of the two parties may then cause the call to go secure. The devices through which communication services are being provided then engage in a secure call setup procedure. This procedure determines the capabilities of the devices, authenticates the callers, passes cryptographic keys, and synchronizes encryption and decryption algorithms. Upon completion of the secure call setup procedure, compatible cryptographic techniques are applied to the information communicated between the communicating devices, and a secure communication session takes place.
Unfortunately, this typical scenario causes some problems. For example, a human factor is involved in deciding when to go secure. If the parties to the call do not manually force the call to go secure, communications are conducted in the clear. This human factor forms a weak link in an overall security scheme. Often, choosing whether or not to go secure is not a clear decision. Confidential, secure, or privileged communications often take place in the clear before the parties to a call recognize that going secure would have been more appropriate. Moreover, when either party to a call may initiating the security provisions, the social decorum associated with determining who should be responsible for initiating security provisions is unclear. Consequently, both parties to a call may hesitate to initiate security provisions, and this hesitancy may lead to a security breach.
Furthermore, conventional secure call setup procedures are undesirably slow. The slowness results from a significant amount of data that are communicated between the terminals during the secure call setup procedure. In addition, slow and cumbersome public encryption processes may be employed to protect cryptographic keys that are exchanged during the procedure. Often times, many seconds must transpire between the initiation of the secure call setup procedure and when the secure communication session may begin. In the course of a conversation, this several seconds may be harmful to the flow of a conversation and provides a subtle motivation against going secure. Moreover, it wastes resources and the time of the parties involved in a communication session.